Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / standards / CCITT / 1992 / X / x509_2.asc < prev next >

Wrap

Text File | 1993-07-15 | 43.5 KB | 1,137 lines

The drawings contained in this Recommendation have been done in AUTOCAD ANNEX A (to Recommendation X.509) Security requirements This Annex does not form an integral part of this Recommendation. [Additional material relevant to this topic can be found in OSI 7498 - Information Processing Systems - OSI Reference Model - Part 2, Security Architecture.] Many OSI applications, CCITT-defined services and non-CCITT-defined services will have requirements for security. Such requirements derive from the need to protect the transfer of information from a range of potential threats. A.1 Threats Some commonly known threats are: a) identity interception: the identity of one or more of the users involved in a communication is observed for misuse; b) masquerade: the pretense by a user to be a different user in order to gain access to information or to acquire additional privileges; c) replay: the recording and subsequent replay of a communication at some later date; d) data interception: the observation of user data during a communication by an unauthorized user; e) manipulation: the replacement, insertion, deletion or misordering of user data during a communication by an unauthorized user; f) repudiation: the denial by a user of having participated in part or all of a communication; g) denial of service: the prevention or interruption of a communication or the delay of time-critical operations; Note - This security threat is a more general one and depends on the individual application or on the intention of the unauthorized disruption and is therefore not explicitly within the scope of the authentication framework. h) mis-routing: the mis-routing of a communication path intended for one user to another; Note - Mis-routing will naturally occur in OSI layers 1 - 3. Therefore mis-routing is outside of the scope of the authentication framework. However, it may be possible to avoid the consequences of mis-routing by using appropriate security services as provided within the authentication framework. i) traffic analysis: the observation of information about a communication between users (e.g. absence/presence, frequency, direction, sequence, type, amount, etc.). Note - Traffic analysis threats are naturally not restricted to a certain OSI layer. Therefore traffic analysis is generally outside the scope of the authentication framework. However, traffic analysis can be partially protected against by generating additional unintelligible traffic (traffic padding), using enciphered or random data. A.2 Security services In order to protect against perceived threats, various security services need to be provided. Security services as provided by the authentication framework are performed by means of the security mechanisms described in A.3 of this Annex. a) peer entity authentication: this service provides corroboration that a user in a certain instance of communication is the one claimed. Two different peer entity authentication services may be requested: - single entity authentication (either data origin entity authentication or data recipient entity authentication); - mutual authentication, where both users communicating authenticate each other. When requesting a peer entity authentication service, the two users agree whether their identities will be protected or not. The peer entity authentication service is supported by the authentication framework. It can be used to protect against masquerade and replay, concerning the user's identities; b) access control: this service can be used to protect against the unauthorized use of resources. The access control service is provided Fascicle VIII.8 - Rec. X.511 PAGE21 by the Directory or another application and is therefore not a concern of the authentication framework; c) data confidentiality: this service can be used to provide for protection of data from unauthorized disclosure. The data confidentiality service is supported by the authentication framework. It can be used to protect against data interception; d) data integrity: this service provides proof of the integrity of data in a communication. The data integrity service is supported by the authentication framework. It can be used to detect and protect against manipulation; e) non-repudiation: this service provides proof of the integrity and origin of data - both in an unforgeable relationship - which can be verified by any third party at any time. A.3 Security mechanisms The security mechanisms outlined here perform the security services described in A.2. a) autbhentication exchange: there are two grades of authentication framework: - simple authentication: relies on the originator supplying its name and password, which are checked by the recipient; - strong authentication: relies on the use of cryptographic techniques to protect the exchange of validating information. In the authentication framework, strong authentication is based upon an asymmetric scheme. The authentication exchange mechanism is used to support the peer entity authentication service; b) encipherment: the authentication framework envisages the encipherment of data during transfer. Either asymmetric or symmetric schemes may be used. The necessary key exchange for either case is performed either within a preceding authentication exchange or off-line any time before the intended communication. The latter case is outside the scope of the authentication framework. The encipherment mechanism supports the data confidentiality service; c) data integrity: this mechanism involves the encipherment of a compressed string of the relevant data to be transferred. Together with the plain data, this message is sent to the recipient. The recipient repeats the compressing and subsequent encipherment of the plain data and compares the results with that created by the originator to prove integrity. The data integrity mechanism can be provided by encipherment of the compressed plain data by either an asymmetric scheme or a symmetric scheme. (With the symmetric scheme, compression and encipherment of data might be processed simultaneously.) The mechanism is not explicitely provided by the authentication framework. However it is fully provided as a part of the digital signature mechanism (see below) using an asymmetric scheme. The data integrity mechanism supports the data integrity service. It also partially supports the non-repudiation service (that service also needs the digital signature mechanism for its requirement to be fully met); d) digital signature: this mechanism involves the encipherment, by the originator's secret key, of a compressed string of the relevant data to be transferred. The digital signature together with the plain data is sent to the recipient. Similarly to the case of the data integrity mechanism, this message is processed by the recipient to prove integrity. The digital signature mechanism also proves the authenticity of the originator and the unambiguous relationship between the originator and the data that was transferred. The authentication framework supports the digital signature mechanism using an asymmetric scheme. The digital signature mechanism supports the data integrity service and also supports the non-repudiation service. A.4 Threats protected against by the security services The table at the end of this Annex indicates the security threats which each security service can protect against. The presence of an asterisk (*) PAGE21 Fascicle VIII.8 - Rec. X.511 indicates that a certain security service affords protection against a certain threat. A.5 Negotiation of security services and mechanisms The provision of security features during an instance of communication requires the negotiation of the context in which security services are required. This entails agreement on the type of security mechanisms and security parameters that are necessary to provide such security services. The procedures required for negotiating mechanisms and parameters can either be carried out as an integral part of the normal connection establishment procedure or as a separate process. The precise details of these procedures for negotiation are not specified in this Annex. SERVICES THREATS Entity Data Data Non- Authentication Confidentiali Integrit Repudiation ty y Identity * (if Interception req'd) Data interception * Masquerade * Replay * * (data) * (identity) Fascicle VIII.8 - Rec. X.511 PAGE21 Manipulation * * Repudiation * ANNEX B (to Recommendation X.509) An introduction to public key cryptography This Annex does not form an integral part of this Recommendation. In conventional cryptographic systems, the key used to encipher information by the originator of a secret message is the same as that used to decipher the message by the legitimate recipient. In public key cryptosystems (PKCS), however, keys come in pairs, one key of which is used for enciphering and the other for deciphering. Each key pair is associated with a particular user X. One of the keys, known as the public key (Xp) is publicly known, and can be used by any user to encipher data. Only X, who possesses the complementary secret key (Xs) may decipher the data. (This is represented notationally by D = Xs[Xp[D]].) It is computationally infeasible to derive the secret key from knowledge of the public key. Any user can thus communicate a piece of information which only X can find out, by enciphering it under Xp. By extension, two users can communicate in secret, by using each other's public key to encipher the data, as shown in Figure B-1/X.509. FIGURE B-1/X.509 - T0704470-88 User A has public key Ap and secret key As, and user B has another set of keys, Bp and Bs. A and B both know the public keys of each other, but are unaware of the secret key of the other party. A and B may therefore exchange secret information with one another using the following steps (illustrated in Figu e B- 1/X.509): 1) A wishes to send some secret information x to B. A therefore enciphers x under B's enciphering key and sends the enciphered information e to B. This is represented by: e = Bp[x]. 2) B may now decipher this encipherment e to obtain the information x by using the secret decipherment key Bs. Note that B is the only possessor of Bs, and because this key may never be disclosed or sent, it is impossible for any other party to obtain the information x. The possession of Bs determines the identity of B. The decipherment operation is represented by: x = Bs[e], or x = Bs[Bp[x]]. 3) B may now similarly send some secret information, xw', to A, under A's enciphering key, Ap: ew' = Ap[xw']. 4) A obtains xw' by deciphering ew': xw' = As[ew'], or xw' = As[Ap[xw']]. By this means, A and B have exchanged secret information x and xw'. This information may not be obtained by anyone other than A and B, providing that their secret keys are not revealed. Such an exchange can, as well as transferring secret information between the parties, serve to verify their identities. Specifically, A and B are identified by their possession of the secret deciphering keys, As and Bs respectively. A may determine if B is in possession of the secret deciphering key, Bs, by having returned part of his information x in B's message xw'. This indicates to A that communication is taking place with the possessor of Bs. B may similarly test the identity of A. It is a property of some PKCS that the steps of decipherment and encipherment can be reversed, as in D = Xp[Xs[D]]. This allows a piece of information which could only have been originated by X, to be readable by any user (who has possession of Xp). This can therefore be used in the certifying of the source of information, and is the basis for digital signatures. Only PKCS which have this (permutability) property are suitable for use in this authentication framework. One such algorithm is described in Annex C. For further information, see: DIFFIE, W. and HELLMAN, M. E. (November 1976) - New Directions in Cryptography, IEEE Transactions on Information Theory, IT-22, No. 6. ANNEX C (to Recommendation X.509) The RSA public key cryptosystem PAGE21 Fascicle VIII.8 - Rec. X.511 This Annex does not form an integral part of this Recommendation. Note - The cryptosystem specified in this Annex, which was invented by R. L. Rivest, A. Shamir and L. Adleman, is widely known as "RSA". C.1 Scope and field of application It is beyond the scope of this paper to discuss RSA fully. However, a brief description is given on the method, which relies on the use of modular exponentiation. C.2 References For further information, see: 1) General RIVEST, R. L., SHAMIR, A. and ADLEMAN, L. (February 1978) - A Method for Obtaining Digital Signatures and Public-key Cryptosystems, Communications of the ACM, 21, 2, 120-126. Fascicle VIII.8 - Rec. X.511 PAGE21 2) Key Generation Reference GORDON, J. - Strong RSA Keys, Electronics Letters, 20, 5, 514-516. 3) Decipherment Reference QUISQUATER, J. J. and COUVREUR, C. (October 14, 1982) - Fast Decipherment Algorithm for RSA Public-key Cryptosystems, Electronics Letters, 18, 21, 905-907. C.3 Definitions a) public key: the pair of parameters consisting of the Public Exponent and the Arithmetic Modulus; Note - The ASN.1 data element subjectPublicKey defined as BIT STRING (see Annex G), should be interpreted in the case of RSA as being of type: SEQUENCE {INTEGER,INTEGER} where the first integer is the Arithmetic Modulus and the second is the Public Exponent. The sequence is represented by means of the ASN.1 Basic Encoding Rules. b) secret key: the pair of parameters consisting of the Secret Exponent and the Arithmetic Modulus. C.4 Symbols and abbreviations X,Ydata blocks which are arithmetically less than the modulus n the Arithmetic Modulus e the Public Exponent d the Secret Exponent p,qthe prime numbers whose product forms the Arithmetic Modulus (n). Note - While the prime numbers are preferably two in number, the use of a Modulus with three- or more prime factors is not precluded. mod n arithmetic modulo n. C.5 Description This asymmetric algorithm uses the power function for transformation of data blocks such that: Y = Xemod n with 0 < X < n X = Ydmod n 0 < Y < n which may be satisfied, for example, by ed mod lcm(p-1,q-1=1, ed mod (p-1)(q-1)=1 To effect this process, a data block must be interpreted as an integer. This is accomplished by considering the entire data block to be an ordered sequence of bits (of length l, say). The integer is then formed as the sum of the bits after giving a weight of 2l-1 to the first bit and dividing the weight by 2 for each subsequent bit (the last bit has a weight of 1). The data block length should be the largest number of octets containing fewer bits than the modulus. Incomplete blocks should be padded in any way desired. Any number of blocks of additional padding may be added. C.6 Security requirements C.6.1 Key lengths It is recognized that the acceptable key length is likely to change with time, subject to the cost and availability of hardware, the time taken, advances in techniques and the level of security required. It is recommended that a value for the length of n of 512 bits be adopted initially, but subject to further study. C.6.2 Key generation The security of RSA relies on the difficulty of factorizing n. There are many algorithms for performing this operation, and in order to thwart the use of any currently known technique, the values p and q must be chosen carefully, according to the following rules [e.g. see Reference 2), Section C.2]: a) they should be chosen randomly; b) they should be large; c) they should be prime; d) |p-q| should be large; e) (p+1) must possess a large prime factor; f) (q+1) must possess a large prime factor; g) (p-1) must possess a large prime factor, say r; h) (q-1) must possess a large prime factor, say s; i) (r-1) must possess a large prime factor; j) (s-1) must possess a large prime factor. PAGE21 Fascicle VIII.8 - Rec. X.511 After generating the public and secret keys, e.g. "Xp" and "Xs" as defined in 3.3 and 4.1 of this Recommendation which consist of d, e and n, the values p and q together with all other data produced such as the product (p-1) (q-1) and the large prime factors should preferably be destroyed. However, keeping p and q locally can improve throughput in decryption by two to four times. The decision to keep p and q is considered to be a local matter [Reference 3)]. It must be ensured that e > log2(n) in order to prevent attack by taking the e'th root mod n to disclose the plaintext. C.7 Public exponent The Public Exponent (e) could be common to the whole environment, in order to minimize the length of that part of the public key that actually has to be distributed, in order to reduce transmission capacity and complexity of transformation (see Note 1). Exponent e should be large enough but such that exponentiation can be performed efficiently with regard to processing time and storage capacity. If a fixed public exponent e is desired, there are notable merits for the use of the Fermat Number F4 (see Note 2). eq F4 = 22\s\up6(4) + 1 = 65537 decimal, and = 1 0000 0000 0000 0001 binary. Note 1 - Although both Modulus n and Exponent e are public, the Modulus should not be the part which is common to a group of users. Knowledge of Modulus "n", Public Exponent "e" and Secret Exponent "d" is sufficient to determine the factorization of "n". Therefore if the modulus was common, everyone could deduce its factors, thereby finding everyone else's secret exponent. Note 2 - The fixed exponent should be large and prime but it should also provide efficient processing. Fermat Number F4 meets these requirements, e.g. authentication takes only 17 multiplications and is on the average 30 times faster than decipherment. C.8 Conformance Whilst this Annex specifies an algorithm for the public and secret functions, it does not define the method whereby the calculations are carried out; therefore there may be different products which comply with this Annex and are mutually compatible. Fascicle VIII.8 - Rec. X.511 PAGE21 ANNEX D (to Recommendation X.509) Hash functions This Annex does not form an integral part of this Recommendation. D.1 Requirements for hash functions To use a hash function as a secure one-way function, it must not be possible to obtain easily the same hash result from different combinations of the input message. A strong hash function will meet the following requirements: a) the hash function must be one-way, i.e. given any possible hash result it must be computationally infeasible to construct an input message which hashes to this result; b) the hash function must be collision-free, i.e. it must be computationally infeasible to construct two distinct input messages which hash to the same result. D.2 Description of a hash function The following hash function ("square-mod n") performs the compression of the data on a block by block basis. Hashing is done in three major steps: 1) The string of data to be hashed is divided into blocks B of equal length. This length is determined by the characteristics of the asymmetric cryptosystem used for signing. With the RSA cryptosystem, this length (in octets) is the largest integer, l, such that, with modulus n, 16 l < log2 n. 2) For non-invertibility reasons each octet of the block is split in half. Each of the halves is headed ("padded") by binary ones. By this zoning, stiffness r redundancy is introduced that increases the non- invertibility property of the hash function considerably. Each block generated in step 1 is spread to the length of the modulus n. 3) Each block resulting from step 2 is added to the previous block modulo 2, squared, and reduced modulo n, until all m blocks are processed. The result is thus the value Hm, where H0 = 0 Hi = (Hi-1 + Bi)2 mod n, for 1 < i < m If the last block of the data to be hashed is incomplete, it is padded with "l"s. ANNEX E (to Recommendation X.509) Threats protected against by the strong authentication method This Annex does not form an integral part of this Recommendation. The strong authentication method described in this Recommendation offers protection against the threats as described in Annex A for strong authentication. In addition, there is a range of potential threats that are specific to the strong authentication method itself. These are: Compromise of the user's secret key - one of the basic principles of strong authentication is that the user's secret key remain secure. A number of practical methods are available for the user to hold his secret key in a manner that provides adequate security. The consequences of the compromise are limited to subversion of communication involving that user. Compromise of the CA's secret key - that the secret key of a CA remain secure is also a basic principle of strong authentication. Physical security and "need to know" methods apply. The consequences of the compromise are limited to subversion of communication involving any user certified by that CA. Misleading CA into producing an invalid certificate - the fact that CAs are off-line affords some protection. The onus is on the CA to check that purported strong credentials are valid before creating a certificate. The consequences of the compromise are limited to subversion of communication involving the user for whom the certificate was created, and anyone impacted by the invalid certificate. Collusion between a rogue CA and user - such a collusive attack will defeat the method. This would constitute a betrayal of the trust placed in the CA. The consequences of a rogue CA are limited to subversion of communication involving any user certified by that CA. Forging of a certificate - the strong authentication method protects against the forging of a certificate by having the CA sign it. The method depends PAGE21 Fascicle VIII.8 - Rec. X.511 on maintaining the secrecy of the CA's secret key. Forging of a token - the strong authentication method protects against the forging of a token by having the sender sign it. The method depends on maintaining the secrecy of the sender's secret key. Replay of a token - the one- and two-way authentication methods protect against the replay of a token by the inclusion of a timestamp in the token. The three-way method does so by checking the random numbers. Attack on the cryptographic system - the likelihood of effective cryptanalysis of the system, based on advances in computational number theory and leading to the need for a greater key length are reasonably predictable. ANNEX F (to Recommendation X.509) Data confidentiality This Annex does not form an integral part of this Recommendation. F.1 Introduction The process of data confidentiality can be initiated after the necessary keys for encipherment have been exchanged. This might be provided by a preceding authentication exchange as described in 9 or by some other key exchange process, the latter being outside the scope of this document. Data confidentiality can be provided either by the application of an asymmetric or symmetric enciphering scheme. F.2 Data confidentiality by asymmetric encipherment In this case Data Confidentiality is performed by means of an originator enciphering the data to be sent using the intended recipient's public key: the recipient will then decipher it using its secret key. F.3 Data confidentiality by symmetric encipherment In this case Data Confidentiality is achieved by the use of a symmetric enciphering algorithm. Its choice is outside the scope of the authentication framework. Where an authentication exchange according to 9 has been carried out by the two parties involved, then a key for the usage of a symmetric algorithm can be derived. Choosing secret keys depends on the transformation to be used. The parties must be sure that they are strong keys. This Recommendation does not specify how this choice is made, although clearly this would need to be agreed by the parties concerned, or specified in other standards. Fascicle VIII.8 - Rec. X.511 PAGE21 ANNEX G (to Recommendation X.509) Authentication framework in ASN.1 This Annex is part of the Recommendation. This Annex includes all of the ASN.1 type, macro and value definitions contained in this Recommendation in the form of the ASN.1 module, "AuthenticationFramework". AuthenticationFramework {joint-iso-ccitt ds(5) modules(1) authenticationFramework(7)} DEFINITIONS ::= BEGIN EXPORTS AlgorithmIdentifier, AuthorityRevocationList, CACertificate, Certificate, Certificates, CertificationPath, CertificateRevocationList, UserCertificate, CrossCertificatePair, UserPassword, ALGORITHM, ENCRYPTED, PROTECTED, SIGNATURE, SIGNED; IMPORTS informationFramework, selectedAttributeTypes, upperBounds FROM UsefulDefinitions {joint-iso-ccitt ds(5)modules(1) usefulDefinitions(0)} Name, ATTRIBUTE,ATTRIBUTE-SYNTAX FROM InformationFramework informationFramework ub-user-passwordFROM Upper Bounds upperBounds; -- types Certificate ::= SIGNED SEQUENCE{ version [0] Version DEFAULT 1988, serialNumber SerialNumber, signature AlgorithmIdentifier, issuer Name, validity Validity, subject Name, subjectPublicKeyInfo SubjectPublicKeyInfo} Version ::= INTEGER { 1988(0)} SerialNumber ::= INTEGER Validity ::= SEQUENCE{ notBefore UTCTime notAfter UTCTime} SubjectPublicKeyInfo ::= SEQUENCE{ algorithm AlgorithmIdentifier PAGE21 Fascicle VIII.8 - Rec. X.511 subjectPublicKey BIT STRING} AlgorithmIdentifier ::= SEQUENCE{ algorithm OBJECT IDENTIFIER, parameters ANY DEFINED BY algorithm OPTIONAL} Certificates ::= SEQUENCE{ certificate Certificate, certificationPath ForwardCertificationPath OPTIONAL} ForwardCertificationPath ::= SEQUENCE OF CrossCertificates Fascicle VIII.8 - Rec. X.511 PAGE21 CertificationPath ::= SEQUENCE{ userCertificate Certificate, theCACertificates SEQUENCE OF CertificatePair OPTIONAL} CrossCertificates ::= SET OF Certificate CertificateList ::= SIGNED SEQUENCE{ signature AlgorithmIdentifier, issuer Name, lastUpdate UTCTime, revokedCertificates SIGNEDSEQUENCE OF SEQUENCE{ signature AlgorithmIdentifier, issuer Name, userCertificate SerialNumber, revocationDate UTCTime} OPTIONAL} CertificatePair ::= SEQUENCE{ forward [0] Certificate OPTIONAL, reverse [1] Certificate OPTIONAL - -at least one of the pair must be present --} --attribute types UserCertificate ::= ATTRIBUTE WITH ATTRIBUTE-SYNTAXCertificate CACertificate ::= ATTRIBUTE WITH ATTRIBUTE-SYNTAXCertificate CrossCertificatePair ::= ATTRIBUTE WITH ATTRIBUTE-SYNTAXCertificatePair CertificateRevocationList ::= ATTRIBUTE WITH ATTRIBUTE-SYNTAXCertificateList AuthorityRevocationList ::= ATTRIBUTE WITH ATTRIBUTE-SYNTAXCertificateList UserPassword ::= ATTRIBUTE WITH ATTRIBUTE-SYNTAX OCTETSTRING(SIZE(0...ub-user-password)) PAGE21 Fascicle VIII.8 - Rec. X.511 MATCHES FOR EQUALITY -- macros ALGORITHM MACRO ::= BEGIN TYPE NOTATION ::= "PARAMETER" type VALUE NOTATION ::= value(VALUE OBJECT IDENTIFIER) END -- of ALGORITHM ENCRYPTED MACRO ::= BEGIN TYPE NOTATION ::= type (ToBeEnciphered) VALUENOTATION ::= value (VALUE BIT STRING - -the value of the bit string is generated by - -taking the octets which form the complete - -encoding (using the ASN.1 Basic Encoding Rules) - -of the value of the ToBeEnciphered type and - -applying an encipherment procedure to those octets-- END Fascicle VIII.8 - Rec. X.511 PAGE21 SIGNED MACRO ::= BEGIN TYPE NOTATION ::= type (ToBeSigned) VALUE NOTATION ::= value(VALUE SEQUENCE{ ToBeSigned, AlgorithmIdentifier, -- of the algorithm used to generate the signature ENCRYPTED OCTET STRING - -where the octet string is the result - -of the hashing of the value of - -"ToBeSigned"- -} ) END -- of SIGNED SIGNATURE MACRO ::= BEGIN TYPE NOTATION ::= type (OfSignature) VALUE NOTATION ::= value(VALUE SEQUENCE{ AlgorithmIdentifier, - -of the algorithm used to compute the signature ENCRYPTED OCTET STRING - -where the octet string is a function (e.g. a compressed or hashed version) - -of the value "OfSignature", which may include the identifier of the --algorithm used to compute the signature- -} ) END -- of SIGNATURE PROTECTED MACRO ::= SIGNATURE END- -of Authentication Framework Definitions ANNEX H (to Recommendation X.509) Reference Definition of algorithm object identifiers This Annex is not an integral part of the Recommendation. This Annex defines object identifiers assigned to authentication and encryption algorithms, in the absence of a formal register. It is intended to make use of such a register as it becomes available. The definitions take the form of the ASN.1 module, AlgorithmObjectIdentifiers. AlgorithmObjectIdentifiers {joint-iso-ccitt ds(5) modules(1) algorithmObjectIdentifiers(8)} DEFINITIONS ::= PAGE21 Fascicle VIII.8 - Rec. X.511 BEGIN EXPORTS encryptionAlgorithm, hashAlgorithm, signatureAlgorithm, rsa,squareMod-n,sqMod-nWithRSA; IMPORTS algorithm,authenticationFramework FROM UsefulDefinitions {joint-iso-ccitt ds(5)modules(1) usefulDefinitions(0)} Fascicle VIII.8 - Rec. X.511 PAGE21 ALGORITHM FROM AuthenticationFramework authenticationFramework; -- categories of object identifier encryptionAlgorithm OBJECT IDENTIFIER ::= {algorithm 1} hashAlgorithm OBJECT IDENTIFIER ::= {algorithm 2} signatureAlgorithm OBJECT IDENTIFIER ::= {algorithm 3} -- algorithms rsa ALGORITHM PARAMETER KeySize ::= {encryptionAlgorithm 1} KeySize ::= INTEGER sqMod-n ALGORITHM PARAMETER BlockSize ::= {hashAlgorithm 1} BlockSize ::= INTEGER sqMod-nWithRSA ALGORITHM PARAMETER KeyAndBlockSize ::= {signatureAlgorithm 1} KeyAndBlockSize ::= INTEGER END -- of Algorithm Object Identifier Definitions PAGE21 Fascicle VIII.8 - Rec. X.511